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@) PROCEDE DE GENERATION AUTOMATIQUE DUN MODULE DUNE BASE ^INFORMATIONS 
D f ADMINISTRATION DE RESSOURCES INFORMAT1QUES. 

(§y Le procede de generation automatique (fun module 
(T9) cfune base d'informations cf administration (MIB) cf une 
ressource informatique (11) representee par objets et in- 
duant une architecture d'objets distribu6s (CORBA) selon 
un langage donne (IDL), consiste a former un fichier (100) 
cfun fichier de description (101 ) et d*un fichier (1 02) de clau- 
ses de generation automatique, une clause comprenant au 
moins un mot cie determinant un mode de generation et au 
moins une caracteristique sur laquelle porte un mot cie, et a 
appliquer le fichier (100) & des moyens de generation (52, 
54) pour obtenir le module. 
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Titre 

Procede de gyration dun module d'une base deformations 
d'administration de ressources informatiques. 

Domaine technique. 

^invention concerne l'administration d'au moins une ressource 
informatique representee dans une technologie orientee objets. La ressource 
informatique peut etre un systeme informatique et/ou un reseau informatique 
et/ou une application informatique. Invention a pour objet un procede de 
generation automatique d'un module d'une base deformations 
d'administration d'un tel systeme. La generation d'un tel module impliquant 
la modification des agents d'administration utilisant ladite base et d'un 
integrates de ces agents, Invention s'appUque aussi a la generation 
automatique d'un tel integrates d'agents d'administration. 

^invention est plus particulierement adaptee a un systeme 
informatique incluant une architecture d'objets distribues, telle que 
l'architecture CORBA (Common Object Request Broker Architecture) definie 
par le groupement de fournisseurs et d'utilisateurs travaillant a la 
normalisation de la gestion des objets et connu sous le nom OMG (Object 
Management Group) et l'architecture OLE/COM (Object Linking and 
Embedding / Component Object Modeler) de Microsoft. L'architecture CORBA 
sera prise comme exemple non limitatif dans la suite du texte. Dans le 
domaine de lWormatique distribute, l'architecture CORBA pennet de 
decrire des interfaces de services informatiques independamment des 
fournisseurs et des langages mettant en oeuvre ces services. La description 
des interfaces est faite a l'aide d'un langage neutre de description dinterface 
connu sous le nom de langage IDL (Interface Definition Language) defini 
aussi par le groupement OMG. Ce langage definit les fcontieres d'un 
composant que constitue un objet gere, c'est-a-dire les interfaces 
contractuelles du composant avec des clients potentiels. 
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I/invention a aussi pour objets corollaixes le systeme 
d'administration et le systeme informatique qui mettent en ceuvre le procede. 

L'art ant6rieur. 

5 L'administration de ressources informatiques est ordinairement 

faite par une plate-forme logicielle d'administration dont on conn ait plusieurs 
types. La plate-forme qui servira d'exemple par la suite est celle connue sous 
le nom de marque d6pos6e OpenMaster, commercialism par le demandeur. 
Cette plate-forme se fonde sur une technologie & objets. Selon cette 

io technologie, les moyens constituant la ressource informatique sont convertis 
en classes d'objets organises hierarchiquement dans une base deformations 
d'administration MIB (Management Information Base). IAnvention 
s'applique & la g6n6ration d'une partie, nominee module, de cette base. 

D'autre part, la plate-forme servant d'exemple utilise le protocole 

15 normalise de communication dedie k Padministration connu sous le nom de 
protocole CMIP (Common Management Information Protocol). Le protocole 
CMIP repose sur la norme ISO definissant les services pour le transfert des 
informations d'administration appeles services CMIS (Common Management 
Information Services). Ce protocole est organist selon un langage de 

20 description des informations d'administration appele langage GDMO/ASN.l 
issu de directives pour la definition d'objets ger£s (Guidelines for the 
Definition of Managed Objects) selon le module dinterconnexion connu sous 
le nom de marque d£pos6e OSI (Open Systems Interconnection) de 
I'organisme international de normalisation ISO (International Standards 

25 Organisation), et de syntaxe ASNl (Application Syntax Notation One). Pour 
des raisons de commodite, ce langage sera appele simplement GDMO. 

Un probldme se pose quand l'administration de ressources 
informatiques au moyen de cette plate-forme utilise une architecture d'objets 
distribu£s telle que CORBA. Cette administration concerne non seulement 

30 l'architecture CORBA elle-meme, mais aussi les services ^applications 
coop&rant avec cette architecture. Ces services peuvent etre administres par 
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1-intemediaire d'une interface d'administration publiee, decrite dans le 
langage IDL de l'architecture CORBA. A partir d'une description en langage 
IDL d'une interface d'un service CORBA. un compilateur IDL genere dans un 
langage de programmation, par exemple C++. d« code dont une partie. 
connue sous le nom normalise "skeleton", pennet de mettre en ceuvre le 
service et dont une autre partie, connue sous le nom normalise "stub", pennet 
d'appeler le service a partir d'un autre programme sous forme de 
bibliotheque. L'agent mis en ceuvre comme service particulier de CORBA a 
done une interface decrite en langage IDL. Cette description est aussi la 
description de reformation d'administration offerte par l'agent. Le langage 
IDL sert ainsi a la fois de langage de description d-interface et de langage de 
description d'information d'administration. 

Le procede de generation automatique d'un module d'une base 
dinformations d'administration d'une ressource informatique representee par 
objets et incluant une architecture d'objets distribute CORBA selon le 
langage IDL. consiste actuellement a faire un fichier de description 
d«interface dans le langage IDL. a faire une conversion automatique du 
fichier et a compiler le fichier de description pour obtenir le module. 

Plusieurs algorithmes de conversion sont connus, tela que ceux 
publies par le group* JIDM (Joint Inter-Domain Management) du groupe 
ORG Cependant. ces algorithmes ne suffisent actuellement pas pour obtenir 
une version complete et exploitable en langage GDMO d'un module de la base 
MIB. Le probleme est que des notions conceptueUes pouvant etre decrites en 
langage GDMO ne peuvent pas I'etre en langage IDL. Par consequent, on 
n'obtient qu"une partie seulement du module desire de la base MIB. 

La solution actuelle consiste a completer manuellement le code 
genere par la conversion, de facon a utiliser au mieux les caracteristiques du 
langage GDMO. Cette solution a done comme premier inconvenient d'etre 
couteuse en temps et en argent. De plus, ce travail manuel doit etre reproduit 
apres chaque traduction dans le cas de changements du contenu du fichier de 
k» description rendu disponible par un agent CORBA. C'est done une solution 
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ponctuelle, qui doit etre revue et completee pour etre adaptee a chaque cas et 
qui a pour second inconvenient d'etre limitee au cas d'espdce et d'etre 
d'autant plus couteuse qu*il y a de changements de la description. Or, 
1'evolution de cette technologie est rapide et s'avdre done tr£s couteuse. Le 

5 troisieme inconvenient est du au fait que le fichier de description en langage 
IDL est traite par un compilateur, qui oblige la modification de la syntaxe du 
lan gage IDL. La syntaxe est ainsi altera dans le seul but de la faire passer 
dans un generateur exterieur k l'architecture CORBA* 

La generation d un module de base MTB implique directement la 

10 modification des agents d'administration qui servent de liens entre 
l'architecture CORBA et la plate-forme d'administration, ainsi que le 
composant servant d'interface entre ces agents et la plate-forme et appele 
integrateur d'agents. Le meme fichier de description IDL est utilise pour 
modifier les agents et Mntegrateur de ces agents. Alors que la modification 

15 des agents ne pose pas de probldme, la modification de rintegrateur d'agents 
CORBA pose le meme probleme que celui expose precedemment. 

i 

Sommaire de l'invention. 

Un premier but de l'invention est de generer automatiquement 
20 dans une base d*informations d'administration MIB un module plus complet 

que celui fourni par la conversion automatique actuellement disponible, le 

module desire etant suffisamment complet pour etre exploitable pour 

l'administration. Le module genere peut etre nouveau ou r6sulter d'une 

modification d'un module anterieur. 
25 Un second but est de generer un module de base MIB exploitable 

sans alterer le fichier de description IDL. 

Un troisieme but est de g6n£rer un module de base MIB 

exploitable et facilement adaptable aux changements de la description t 

initiate. 

30 Un quatridme but est de generer simplement et k moindre cout 

un module de base MIB exploitable. 
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Un dnquieme but de Invention est, comme consequence de la 
generation du module ^administration, de modifier automatiquement 
l*integrateur d'agents d'administration sans intervention manuelle. 

LWntion a pour objet un precede de generation automatique 

5 d'un module d'une base d-informations d'administration (MIB) d'une 
ressource informatique representee par objets et induant une architecture 
d'objets distribues (CORBA) selon un langage donne (IDL), consistant a faire 
un ficbier de description d'interface dans le langage donne et a appliquer 
ledit fichier a des moyens de generation automatique pour obtenir une partie 

,o dudit module, caracterise en ce qull consiste a ajouter audit ficbier de 
description un ficbier de clauses de generation automatique. une clause 
comprenant au moins un mot de determinant un mode de generation et au 
moins une caracteristique sur laquelle porte un mot de. et a appliquer le 
fichier de dauses auxdits moyens de generation pour completer ledit module. 

,5 Accessoirement. le fichier de dauses et le fichier de description 

ne ferment quMn seul fichier. lMn des deux fichiers etant distingue de l'autre 

par une marque. 

De meme, les moyens de generation comprennent en outre un 
generates (54) pour la generation automatique d'une partie d'un integrates 
20 d'agents d'administration. 

Linvention a aussi pour objet un ysteme d'administration d'une 
ressource informatique representee par objets definis dans une base 
d-informations d'administration (MIB) induant un module, la ressource 
informatique induant une architecture d'objets distribues (CORBA) selon un 
25 langage donne (IDL). caracterise en ce qull met en oeuvre ledit precede. 

Presentation des dessins. 

- La figure 1 est une vue synoptique d'un systeme 
d'administration d'un systeme informatique, le systeme d'administration 
30 mettant en oeuvre un precede de generation automatique d'un module d'une 



2793908 



-6- 

base MIB et du proced6 en resultant pour la g6n6ration automatique d'un 
integrateur d'agents d'administration. 

- La figure 2 est une vue synoptique detaillee de la structure 
d\ine plate-forme d'administration du systeme d'administration repr6sente 

s sur la figure 1. 

- La figure 3 est une vue schematique d'un arbre repr6sentatif 
d'un exemple de base MIB correspondant au systdme infonnatique repr6sente 
sur la figure 1 et incorporant le module a generer conform&nent k Invention. 

- La figure 4 est une vue schematique d'une architecture d'objets 
10 distribues CORBA en liaison avec un integrateur d'agents CORBA de la 

plate-forme representee sur la figure 2. 

- Et la figure 5 est un organi gramme illustrant schematiquement 
le precede de generation automatique d'un module de base MTB f ce proc6de 
etant aussi utilise pour la generation automatique de rint£grateur d'agents 

13 CORBA repr6sent£ sur la figure 4. 

Description detaillte d'exemples illustrant Tinvention. 

La figure 1 represente un systeme d'administration 10 d'un 
systeme infonnatique 11. L'exemple qui suit se rapporte au systeme 

20 d'administration et de s&urite connu sous le nom de marque depos6e 
OpenMaster du demandeur. Sa conception est conforme aux normes ISO de 
1'administration de systemes et reseaux. Dans ces conditions, les termes 
utilises seront conformes k cette norme, qui sont de langue anglaise, 
notamment les sigles et acronymes. D'autre part, les verbes "administrer" et 

25 "g6rer" et leurs derives qui seront employes ici traduisent tous deux 
indifferemment le verbe anglais "manage" et ses d6riv6s. L'homme du metier 
conn ait Men ces normes. Compte tenu de leur masse informative, on ne 
donnera ici que les elements necessaires a la comprehension de ^invention. 

Le systeme infonnatique illustre 1 1 est distribu6 et compost de 

30 machines 12 (12a, 12b) organisees en un ou plusieurs reseaux 13. Une 
machine est une unite conceptuelle tres large, de nature materielle et 
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logicielle, pouvant etre les moyens impliques pour executer une application 
donnee, des moyens pour executer une fonction donnee, un ordinateur, ainsi 
qu'un systeme infonnatique dans une architecture a systemes en cascade. Les 
machines 12 peuvent etre done tres diverses, telles que stations de travail, 
serveurs, routeurs, machines speaalisees et passereUes entre reseaux. Le 
systeme infonnatique 11 est ordinairement un systeme comprenant plusieurs 
processeurs 14, un processeur 14 etant par exemple iUustre dans chaque 
machine 12, des moyens de memoire 15 pour contenir les logidels et les 
donnees du systeme, et des moyens d'entree-sortie 16 servant pour la 
communication entre machines par l'intermediaire du reseau 13 a l'aide de 
protocoles divers, ainsi que pour une ou plusieurs communications 
exterieures, par exemple pour limpressrion, la telecopie, etc. Un tel systeme 
peut par exemple gerer des donnees a distance, distrihuer des donnees dans 
le cas d'un systeme de reservation, commander l'execution de programmes a 
distance sur des machines speaalisees, partager localement des ressources 
physiques ou logicielles, et communiquer. 

Le systeme d'administration 10 a une architecture de type client- 
serveur. Dans l'exemple illustre, les unites formant clients et serveurs dans le 
systeme d'administration 10 comprennent deux gestionnaires 17a formant 
serveurs et trois agents 17b formant clients. Une machine 12 induant un 
gestionnaire est dite machine gestionnaire ou serveur 12a et une machine 
induant un agent est dite machine geree 12b ou cliente. Les gestionnaires 
17a et les agents 17b sont relies entre eux par l'intermediaire du reseau 13. 
Dans l'exemple illustrt, les deux gestionnaires sont relies entre eux, Tun des 
gestionnaires 17a etant relie a deux des agents 17b tandis que 1'autre est 
relie aux trois agents. Les liaisons entre gestionnaires et agents peuvent etre 
tres diverses. D'autre part, les communications entre gestionnaires et agents 
peuvent se faire selon un ou plusieurs protocoles, de preference normalises 
tels que les protocoles CMTP (deja dtS) et SNMP (System Network 
Management Protocol). Le protocole CMIP repose sur la norme ISO 
definissant les services pour le transfert des informations d'administration 
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appeles services CMIS (Common Management Information Services). Chaque 
protocole est organise selon un langage de description des informations 
d' administration. Par exemple, le protocole SNMP utilise le langage SMI 
(Structure of Management Information) tandis que le protocole CMIP utilise 

5 le langage GDMO/ASN. 1 dejk cite, et simplement appele GDMO. 

La figure 2 illustre la structure d*une plate-forme 
d'administration 20 du systeme d'administration 10. La plate-forme 20 peut 
etre limit£e k une machine gestionnaire 12a, ou etre distribute parmi 
plusieurs machines gestionnaires. Pour des raisons de commodite, la plate- 

10 forme illustree dans la figure 2 sera limitee k une machine gestionnaire 12a 
et correspond ainsi au gestionnaire 17a. La plate-forme illustree 20 se 
compose de cinq blocs fonctionnels : un bloc 30 ^applications en langage SML 
(Systems Management Language), un bloc 40 de services, un bloc 50 
d*integrateurs d'agents, un bloc 60 d'interface de gestionnaire, et un bloc de 

15 communication 70. 

Le bloc 30 ^applications inclut un ensemble ^applications de 
base 31 (core applications), une interface graphique d'utilisateur 32 appelee 
interface GUI (Graphic User Interface), un tableau de bord constituant un 
lanceur ^applications 33, une interface 34 de communication exterieure du 

20 bloc 30, et un ensemble 35 de fonctions de haut niveau. Dans I'exemple choisi, 
les applications 31 sont 6crites dans le langage SML et communiquent avec le 
bloc 70, utilisant le protocole CMIP et le langage GDMO, par ^interface 34 
qui est done ici une interface SML/GDMO. L'interface GUI 32 permet k un 
utilisateur de se connecter k la machine 12a pour d&narrer et arreter comme 

25 il le desire ses prop res copies des applications de base 31. Le lanceur 
d'applications 33 presente un tableau representant les applications 31 sous 
forme generate par leur nom et/ou, comme dans I'exemple choisi, sous forme 
dlcones. D suffit de cliquer sur llcone choisie pour lancer l'application 
correspondante. Les fonctions de haut niveau 35 sont ajout6es pour offirir des 

30 fonctions particulitres et des interfaces graphiques correspondantes. 
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Le bloc 40 comprend plusieurs services, notamment un service 
41 de base de donnees CMIS. appele service CMIS-DB, un service 42 de 
schemas d«informations d'administration ou service MISS (Management 
Information Schema Service), un service 43 de journal d'alarmes et un service 
44 de journal d'evenements normalement connecte a un journal d'evenements 
non illustre. Le bloc 50 illustre contient seulement un integrates 51 d'agents 
d'administration, appele ordinairement par le sigle AI (Agent Integrator) et 
affecte a un protocole particulier, ici le protocole CORBA, d'autres 
integrateurs d'agents pouvant exister pour le protocole SNMP. etc. le 
protocole CMIP est utilise comrae exemple dans la plate-forme 20. 
Lintegrateur 51 d'agents est connecte au bloc 70 et a un ou plusieurs agents 
17b fonctionnant sous le protocole correspondant. ici CORBA. Dans l'exemple 
illustre, le bloc 50 indut aussi des moyens de generation 52, 53 et 54 et des 
moyens de compilation 55 qui, d'une maniere generate, pourraient etre 
contenus dans une partie quelconque de la plate-forme 20. Le bloc dSnterface 
60 permet a la plate-forme 20 de communiquer avec un autre gestionnaire 
17a du systeme 10, pouvant etre un supragestionnaire de niveau 
bierarcbique superieur. Enfin, le bloc de communication 70 constitue un lien 
entre les autres blocs et est appele courtier de requetes CMIS ou distributeur 
CMIS (CMIS Dispatcher). II contient un routeur 71 d'evenements, permettant 
aux composants d'administration de souscrire a des notifications 
d'evenement, un routeur 72 de commandes pour transmettre des requetes au 
composant destinataire et eviter aux applications de savoix quel composant 
-possede" chaque instance MOI. une infrastructure de securite 73, un 
gestionnaire 74 d'objets sous la racine ROOT (ROOT Object Manager), et une 

horloge 75 (timer). 

Selon une option courante et avantageuse du systeme 
d'administration 10, un gestionnaire 17a gere aussi la machine gestionnaire 
12a correspondante ou gere tout ou partie des machines gestionnaires. Cela 
peut se faire de facjra similaire a celle iUustree precedemment, plus ou moins 
adaptee a cette option. L'exemple illustre offire le double avantage de faciHter 
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la lecture des dessins tout en pennettant a l'homme du metier de faire une 
generalisation du systeme decrit et illustre. 

Le systeme infonnatique 1 1 de la figure 1 se compose de moyens 
materiels ou logiciels, r6els ou virtuels t tels que machines, imprim antes, 

5 circuits virtuels et applications. Le systeme d'administration 10 utilise ces 
moyens selon un modele de donnees oriente objets, dont on conn ait les 
principales caracteristiques : classes, objets, heritage, encapsulation, 
methodes (ici actions) et evenements. ^organisation des classes dans 
l'exemple choisi du systeme 10 est hierarchique. On distingue : l'arbre des 

io classes, une classe 6tant definie en subordination & une ou plusieurs classes 
mdres ; et l'arbre des instances, une instance etant attachee £ une ou 
plusieurs instances mdres. En particulier, une classe est definie par des 
caracteristiques nominees attributs, tels qu'un nom d'un composant du 
systeme et un etat depression. Un objet d'une classe sera appele une 

15 instance de la classe. Dans Texemple choisi, les moyens du systeme 
infonnatique 11 sont done convertis en classes d'objets organis6es 
hi£rarchiquement dans une base d'informations d'administration MIB 
(Management Information Base). Cette base n'est pas une base de donnees 
proprement dite, mais est assimilable & un catalogue de caracteristiques 

20 puisqu'elle contient la description et le contenu de toutes les classes ger6es 
par le systeme d'administration 10. Dans la base MIB, les objets sont divises 
en classes d'objets geres, dites classes MOC (Managed Object Class). Un objet 
gere est une vue abstraite, definie pour les besoins de la gestion, d'une 
ressource logique ou physique d'un systeme. Chaque classe MOC represente 

25 un type donne desdits moyens du systeme 11. A chaque classe MOC peuvent 
etre attachees une ou plusieurs instances d'objets g£res, appelees instances 
MOI (Managed Object Instance) et representant des occurrences actuelles 
desdits moyens. 

La figure 3 illustre un exemple de structure d'une base MIB. EUe 
30 a une structure arborescente, faite d'une racine ROOT a laquelle sont 
attaches des sous-arbres ou sous-MIB 18, ici representatifs des trois machines 
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gerees 12b appelees Mac-a, Mac-b et Mac-c. Les sous-arbres 18 sont aussi 
represents sous forme synoptique dans la figure 1, en liaison avec les agents 
17b respectifs. La racine ROOT est contenue dans le gestionnaire 74 et les 
radnes des sous-arbres seront appelees sous-racines correspondant au terme 
anglais Rootlet. Ainsi, toute appUcation 31 devant traiter un objet de la base 
MIB s'adresse au gestionnaire 74 pour acceder a l'objet Dans 1'exemple 
illustre, on a suppose que chaque machine 12b a, comme represent sur la 
figure 1. trois cartes 19, a savoir une carte-reseau R. une carte video V et une 
carte-son A, de sorte que chaque sous-arbre 18 correspondant contient les 
trois objets correspondants. Dans la figure 3, seul le sous-arbre 18 relatif a la 
machine Mac-b a ete developpe. On y voit que le sous-arbre 18 a la sous- 
racine Mac-b induant trois fils constitues par les trois objets respectifs carte- 
reseau, carte video et carte-son (R, V et A). Llnvention s'applique a la 
generation automatique d'une partie de l'arbre. appelee module 
dinformations d'administration 19 et faite d'au moins un objet gere MOC et 
dont la description en langage IDL est issue d'un agent CORBA 51. Le 
module est defini de facon abstraite par un trait fantdme dans la figure 3. 
^invention a pour objet un procede de generation automatique d'un module 
19 a partir d'un fichier de description en langage IDL, ce procede etant mis en 
oeuvre dans un integrateur d'agent 51. 

Une instance dans la base MIB a un nom distinctif relatif RDN 
(Relative Distinguished Name) sous forme d'une liste d'assertions sur valeur 
d'attribut appelees assertions AVA (Attribute Value Assertion). Chaque 
assertion AVA est un couple <attribut de nommage> <valeur>, l'attribut de 
nommage etant celui qui, dans la classe, pennet lidentification unique d'une 
instance par rapport a son instance mere. Dans un gestionnaire 17a de 
l'exemple illustre, un nom RDN est compose d'une seule assertion AVA, done 
d'un seul couple <attribut de nommage> <valeur>. D'une maniere generale, il 
est cependant possible qu'un nom distinctif RDN ait plusieurs assertions 
AVA. Chaque instance dans la base MIB est identifiee de facon unique par 
son nom distinctif DN (Distinguished Name), qui est la suite des noms RDN 
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sur le chemin entre la racine et 1'instance dans Tarbre des instances. Un sous* 
arbre d*une instance correspond a Tensemble form6 par Instance elle-meme 
et les instances qui lui sont subordonn6es dans l'arbre des instances. 

Sous la racine ROOT de la base MIB est attachee une sous- 

5 racine pour chaque service du bloc 40. Dans ce bloc, le service CMIS-DB 41 
fournit une base de donnees des objets geres MOI destin6e a leur persistance 
une fois que le gestionnaire a et6 mis hors fonctionnement. II supporte toutes 
les classes MOC des services CMIS qui sont stockees localement dans une 
base de donnees. En outre, il fournit un ensemble de services ou fonctions de 

io base, appelees aussi primitives, disponibles pour toutes les applications. Ces 
fonctions sont bien adaptees a la structure hierarchique de la base MIB. EDes 
incluent notamment les fonctions : M-GET pour lire une ou plusieurs 
instances, M-SET pour mettre a jour une ou plusieurs instances, M-CREATE 
pour creer une instance, M-ACTION pour activer une operation specifique 

15 sur une ou plusieurs instances et M-EVENT pour envoyer un 6v6nement. Ces 
fonctions supportent les notions de filtrage offrant la possibility de filtrer les 
instances selon certains criteres portant sur leurs attributs et les notions de 
port£e (scope) permettant de preciser le niveau de profondeur dans l'arbre des 
instances. 

20 Le service MISS 42 fournit les moyens dHdentification des objets 

g£r£s, les moyens 6tant ceux definis initialement dans les documents de 
definitions GDMO contenus dans une description GDMO. II permet 
d'ex£cuter des processus de description pour entrer un nouveau jeu de 
definitions en utilisant un compilateur GDMO et des processus de recherche 

25 (retrieval processes) pour savoir comment une information d'administration 
ant&rieurement entree peut etre lue par n'importe quel composant de la 
plate-forme 20. Ces deux processus partagent une base de donnees appetee 
base de schemas d'infonnations d'administration, souvent abregee en base de 
schemas ou base MISB (Management Information Schema Base). EUe sert au 

30 stockage de tous les jeux correctement compiles des definitions dlnformations 
d'administration. La base est modelisee par une base MIB. Cela signifie que 
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la structure de reformation contenue dans la base de schemas est 
logiquement vue comme une base MIB et qu'eUe utilise elle-meme la notation 
GDMO. Cette vue logique de la base de schemas est une partie de la base 
MIB globale accedee par la plate-forme 20 et est appelee base MIB de 
schemas d'infbrmations d'administration. 

Les mecanismes et modalites d'echange entre objets peuvent etre 
regis de diverses facons dans les machines. Parmi elle, l'exemple choisi utilise 
les mecanismes et modalites regis par une architecture d'objets distribues, 
Varchitecture CORBA en roccurrence. Dans le domaine de rinformatique 
distribuee, l'ardritecture CORBA permet de specifier des interfaces de 
services informatiques independamment des fournisseurs et des langages 
mettant en oeuvre ces services. La specification des interfaces est faite a l'aide 
d'un langage neutre de description d'interface connu sous le nom de langage 
IDL (Interface Definition Language) defini aussi par le groupement OMG. Ce 
langage definit les frontieres d'un composant que constitue un objet gere, 
c'est-a-dire les interfaces contractuelles du composant avec des clients 
potentiels. 

On a vu que rintegrateur 51 d'agents sert d'interfaces entre la 
plate-forme 20 et les agents correspondants 17b de Varcbitecture CORBA. 

La figure 4 illustre la structure d'une architecture CORBA 90 en 
liaison avec la plate-forme 20 par Intermediate de rintegrateur d'agent 51 
de type CMIP/CORBA. ^architecture CORBA 90 comprend : un courtier 91 
de requetes d'objets ou courtier ORB (Object Request Broker) definissant un 
bus des objets CORBA ; un ensemble 92 de services CORBA definissant les 
infrastructures d'objets au niveau systeme qui etendent le bus ; un ensemble 
93 ^applications CORBA ; un ensemble 94 d*installations CORBA (CORBA 
facilities) definissant les infrastructures horizontales et verticales qui sont 
utilisees directement par les objets d'affaire (business objects) ; et un 

compilateur IDL 95. 

Comme il a ete dit en introduction, le precede connu de 
generation d'un module de base MIB consiste a utiliser un fichier de 



2793908 



-14- 

description BDL tel qu'indique dans Tannexe IB a la presente demande, qui 
fait partie de la description et a appliquer le fichier & un g6n6rateur 52 pour 
obtenir une partie dudit module, 

Pour la realisation du generateux 52, on connait plusieurs 
algorithmes de conversion, notamment les algorithmes d'administration 
inter-domaine et connus sous le nom JIDM (Joint-Inter-Domain 
Management) issus du groupement OMG. Cependant, ils ne suffisent pas 
pour obtenir une version complete et exploitable en langage GDMO. Cette 
insuffisance est due au fait que des notions conceptuelles pouvant etre 
decrites en langage GDMO ne peuvent pas Tetre en langage IDL. Ces notions 
sont notamment : 

- la definition des attribute de nommage, 

- des regies de construction d'arbres connus sous le nom de liens 
de nommage et plus ordinairement name-binding, 

- Tallocation d*identifieurs d'objets, et 

- Tutilisation d'une meme description d'attribut dans des 
interfaces differentes. 

La solution k ce probldme consiste & ajouter au fichier de 
description IDL de Tannexe IB des commentaires pour la conversion, tels que 
ceux illustres dans Tannexe 1A. Selon Texemple de Tannexe 1, les 
commentaires de Tannexe 1A sont contenus dans une zone de commentaires 
solidaire du fichier de description IDL de Tannexe IB, la zone de 
commentaires pouvant pr6c6der ou suivre la description IDL. Dans ce cas, la 
zone se distingue des autres commentaires de la description IDL (annexe IB) 
par une marque, en Toccurrence la marque GEN. Selon une variante possible, 
les commentaires de Tannexe 1A pourraient etre contenus dans un fichier 
similaire & la zone illustree mais independant du fichier de description IDL. 
Dans ce cas, il suffit d'appeler le fichier de commentaires pour completer la 
description IDL. Ainsi, la description IDL peut toujours etre pass6e au 
travers du compilateur IDL 95, avec les memes rtsultats, puisque la syntaxe 
du langage n'est pas modiftee. 
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La figure 5 iUustre schematiquement le procede. Le bloc 100 
comprend le ficbier constitue du fichier de description IDL 101 illustre dans 
l'annexe 1A et la zone de commentates 102 illustre dans l'annexe IB. Le 
fichier 100 est applique a Tentree du premier generateur 52 pour generer le 
module 19 de base MIB. Le module 19 est done un fichier de description en 
langage GDMO. Le module 19 est ensuite integre dans la base MIB. En 
pratique, dans l'exemple illustre, Integration du module 19 dans la base 
MIB est faite par compilation du module 19. La compilation est faite ici par le 
compilateur GDMO 55 illustre dans la figure 2. Le module 19 est directement 
assimilable par le compilateur 55. Le compilateur 55 a pour nom gdmoc dans 
le produit OpenMaster de l'exemple consider*. II prend la description GDMO 
du module 19 en entree, en verifie la syntaxe et entre cette description dans 
la base MISS 42 de la figure 2 pour rendre disponible la description aux 
services 40 et aux applications 31 de la plate-forme 20. 
15 La figure 5 illustre aussi un procede en resultant pour la 

generation automatique de Integrates 51. Cet integrates tel qu'illustre 
sert a la conversion du langage IDL en protocole CMIP. Un agent integrates 
CORBA 17b de la figure 2 est forme selon la technique anterieure, qui 
consiste a appliquer le fichier de description IDL 101 de l'annexe IB a l'entree 
20 du compilateur IDL 95. Une premiere partie 51a de Integrates 51 est faite 
aussi a partir du compilateur 95. En fait, le compilateur 95 fournit une partie 
dite -skeleton" a l'agent CORBA et une partie dite "stub" a integrates 51 
pour en constituer la premiere partie 51a. Une seconde partie 51b de 
integrates 51 est aussi faite selon la technique anterieure, qui consiste a 
25 appliquer le module 19 de description GDMO au second generateur 53, 
adapte a la generattion automatique d'integrates d'agent a partir dune 
description GDMO. cet outil etant appele OPAL/ADK dans le produit 
OpenMaster®. A noter toutefois que dans la technique anterieure, le module 
GDMO etait celui complete manuellement alors que dans Invention, U est 
30 g6nere en entier automatiquement. Selon llnvention, une troisieme partie 
55c de Kntegrateur 51 est faite simplement et automatiquement a partir du 
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fichier 100 au moyen du troisieme generateur 54. Le g6n6rateur 54 convertit 
le langage IDL du fichier 100 en un langage, par exemple C et/ou C++ qui 
sert a faire un lien entre la partie 56a gener£e k partir du langage IDL et la 
partie 56b generee a partir du langage GDMO. 

5 Les commentaires illustr6s en annexe 1A sont donnes a titre 

indicatif et vont maintenant etre commentes. On a vu que la marque GEN est 
ajoutee au debut d'un commentaire pour etre interpretee par les g6n£rateurs 
52 et 54 comme debut de commentaire. Les commentaires se composent de 
clauses ay ant chacune leur signification pour le g£n6rateur 52. Une clause se 

10 compose d'au moins un mot cle s'appliquant a au moins un attribut qui le 
suit. Les clauses illustrees en annexe sont classees en plusieurs types qui ont 
et£ numerates par les lettres A-E en italique et entre parentheses dans le seul 
but de faciliter leur presentation. Cette presentation est faite aussi en 
reference & l'annexe 2 & la prdsente description et en en faisant partie. 

15 L'annexe 2 donne simplement une liste explicative des types des clauses 
utilisees, ici A-H. 

Dans l'annexe 1A, la clause de type A se compose du mot cle 
METHOD_TO_ATTRIBUTE suivi d"une methode, ici getjabel, et d'un 
attribut, ici label. Selon l'annexe 2, cette clause indique aux ggn&rateurs 52 et 

20 54 de convertir la methode getjabel en l'attribut label. On notera que le 
convertisseur 52 de services CMIS ne generera aucun service M-ACT10N 
mais que les generateur 52 genereront l'attribut specLfie. En d'autres termes, 
un clause du type (A) comprend un mot cle (METHOD JTO.ATTRTOUTE), 
une premidre caract^ristique representative du nom d*une methode et une 

25 seconde caracteristique representative d'un attribut, le mot cle indiquant au 
generateur de convertir ladite methode en ledit attribut. 

Dans l'annexe 1A, la clause de type B a le mot cle 
MULTIPLE_DECLARE, qui signifie aux generateurs 52 et 54 qu*ils vont 
trouver une premidre interface induant l'attribut qui le suit, ici "hostname" 

30 et une seconde interface incluant aussi cet attribut. II est k noter qu'en 
langage GDMO il est possible d'utiliser la meme definition d'attribut dans des 
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classes differentes d'objets geres (dasses MOC). Ainsi, quand les generateurs 
trouvent la premiere interface, ils generent une premiere classe MOC a partir 
de cette premiere interface et, de meme, quand les generateurs trouvent la 
seconde interface, ils generent une seconde classe MOC a partir de cette 
seconde interface. Ik utilisent done le meme attribut, ici "hostname" dans le 
langage GDMO. En bref, clause du second type B comprend un mot de 
(MULTIPLE_DECLARE) et un attribut, le mot de indiquant au generateur 
de generer des dasses d'objets a partir dudit attribut. 

Dans les commentaires de l'annexe 1A, la dause de type C a le 
mot de IGNORE, qui signifie aux generateur de ne pas traduire le terme IDL 
qui le suit. Le terme peut etre notamment un nom dlnterface, un nom 
d'exception, un nom d'attribut et un nom de methode. Dans l'exemple illustre, 
le terme est un attribut nomme "ActualAttributeValue_t". En d'autres termes, 
les generateurs ne modifient pas le langage IDL pour la conversion. Ce mot 
de otire l'avantage de ne pas generer des choses inutiles dans la description 
GDMO, cela sans toucher au fichier de description IDL. 

La dause de type D a le mot de TYPEDEF. qui indique aux 
generateurs 52 et 54 qu'il faut remplacer le premier mot qui le suit, 
representatif d'un type du langage GDMO, id 'InterfaceDef par le second 
mot representatif d'un type du langage IDL, id "Objecr, normalement defini 
par une partie code dans le fichier de description de l'annexe IB, cette partie 
de code commenc*nt id par un terme nomme "indude" et reference par le 
caxactere Cette dause permet de faire des synonym es entre les deux 
langages correspondants. En fait, cette dause est un moyen de definir un 
type de donnees utilise en langage IDL a partir du type de base. Cette 
definition est normalement faite par le verbe "typedef du langage IDL et est 
importee dans le fichier de description a l'aide des termes "indude". Cette 
dause s'explique par l'incapadte des generateurs de l'exemple illustre, pour 
des raisons de limitations imposees par la realisation de ces generateurs, de 
chercher les termes "indude" dans le fichier de description IDL. Comme la 
version courante des generateurs utilises dans l'exemple choisi ne gere pas 
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les clauses de precompilation qui commencent par le caract^re dans le 
fichier de description IDL de l'annexe IB, il a ete ajoute au fichier de l'annexe 
1A du code qui est present avec les termes -include* et n6cessaire & la 
conversion au debut du fichier de description de l'annexe IB. En outre, dans 

5 le fichier de description de l'annexe IB, il est ajoute une premiere marque 
suivi d'un terme non defini, ici "Mfdef FORjGENERATORjnME* et une 
seconde marque "#endif (non illustree). Ainsi, le compilateur 55 de la figure 
2 ignore ce qui est entre ces deux marques puisque le terme 
"FORjGENERATORJHME " n'est pas defini. Dans le compilateur, le 

10 pr6processeur (non illustre), qui g6n6re du code C++ k partir du fichier de 
description, 6jecte la partie entre les deux marques alors que les deux 
generateurs 54 et 55 vont les prendre en compte. En d'autres termes, on peut 
dire que si les generateurs 52 et 54 ne gdrent pas des clauses de 
precompilation, une clause de troisi&ne type (D) inclut un mot d6 

15 (TYPEDEF) et deux mots, le mot de indiquant aux generateurs 52 et 54 quil 
faut remplacer Tun (InterfaceDef) des deux mots, representatif d'un type 
dudit module, par l'autre mot (Object) representatif d'un type du langage 
donne IDL normalement defini par une partie de code (sous #include) dans le 
fichier de description. 

20 Les clauses de type E dans les commentaires de l'annexe 1A sont 

relatives aux liens de nommage, appeles name-binding. Ces clauses sont dues 
au fait qu'il n f y a pas de liens de nommage entre classes en langage IDL mais 
qu41 en existe en GDMO. Cette clause permet ainsi d'introduire des liens de 
nommage name-binding dans une definition. Les clauses de type E 

25 comprennent trois mots cles SUPER, SUBORD et NAME, suivis 
respectivement de mots (caracteristiques d'objets, attributs, etc.). Le mots cl^s 
SUPER et SUBORD d&ignent respectivement les classes superieures et 
subordonn^es d'objets et le mot cle NAME designe Tattribut de nommage de 
la dasse subordonnee. Par exemple, la clause "SUPER orb SUBORD 

30 AgentSystem NAME hostname" indique qu*une instance de la dasse 
"AgentSystem" peut se trouver sous, ou etre contenue dans, une instance de 
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la dasse "orb" et qu'elle est nominee, en tant qu'attribut utilise pour le nom 
RDN, avec l'attribut "hostname" qui appartient a la dasse "AgentSystem". En 
d'autres termes, une dause de quatrieme type (E) comprend trois mots des 
(SUPER, SUBORD, NAME correspondant respectivement a trois 
5 caracteristiques (orb, AgentSystem, hostname), deux des mots des designant 
par leurs caracteristiques correspondantes deux instances de dasses 
respectivement superieure et inferieure et le troisieme mot de designant par 
la troisieme caracteristique l'attribut de nommage de la dasse subordonnee. 

Les dauses de types F et G de l'annexe 2 sont des dauses 
10 introductives. Ainsi, la dause de type G sert a nommer le module GDMO 
genere par le generateur 54 et la dause de type H sert a nommer le module 
ASN1 genere par le generateur 55. 

La dause de type H de l'annexe 2 necessite les observations 
preliminaires suivantes. Tous les objets semantiques GDMO generes (MOC, 
15 NameBinding, Package, Attribute) sont identifies par des identifieurs d'objets 
(Object IDentifiers) tels que definis par la norme ASN1. Ces identifieurs sont 
des suites d'entiers reprenant un meme prefixe. Par exemple, si on alloue la 
suite "1 3 12" comme prefixe, on allouera automatiquement dans la 
generation automatique les identifieurs "1 3 12 1 1", "1 3 12 1 2", "1 3 
20 12 1 3", "1 3 12 1 4", ... pour identifier les dasses MOC, puis les 
identifieurs "1 3 12 2 1", "1 3 12 2 2", "1 3 12 2 3". "1 3 12 2 4", ... 
pour identifier les liens de nommage name-binding, etc La dause de type J 
pennet de demander aux generateurs 54 et 55 de prendre un prefixe different 
de ceux definis precedemment. Selon notre exemple, la dause "OID_TAG 15" 
25 demandeau generateur de changer le prefixe precedent, id "1 3 12"en"l 3 
15".En fait, Jes identifieurs sont generes a l'aide du prefixe, qui est alloue 
dans le systeme d'administration 10 pour le systeme COBA et auqud est 
ajoute un entier supplementaire, le nombre 15 dans l'exemple illustre. Cet 
entier supplementaire sert a distinguer des generations en langage IDL entre 
30 elles et, done, a distinguer entre eux des modules de base MIB differents. 
Ainsi. sll existe plusieurs types d'agents implementant des modules 
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differents de base MIB, il est possible de voir tous ces agents dans la base 
MIB du syst£me d'administration 10. En d'autres termes, si les objets sont 
identifies par des identifieurs (OID) ayant un meme prefixe, une clause de 
cinquidme type (H) comprend un mot de (OID.TAG) et un entier (15), le mot 
cl6 indiquant au g6n6rateur de prendre un prefixe different et defini par ledit 
entier. 
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ANNEXE 1A 



10 



15 



20 



25 



30 



35 



(zone de commentaires) 



II- 



//GEN. METHOD_TO^ ATTRIBUTE get Jabel label 



(A) 
II— 



//GEN: MULTDPLE.DECLARE hostname 
//GEN: MULTIPLE_DECLARE value 

// 

//GEN: IGNORE ActualAtlributeValueJ 
//GEN: IGNORE AtlributeRefercnceJ 

// 

//GEN: TYPEDEF InterfaceDef Object 
//GEN: TYPEDEF event Jype_schemaJ string 
//GEN: TYPEDEF AttriboteDef Object 
//GEN: TYPEDEF OperationDef Object 

II _ 

//name-bindings : 
(E) 

II 



(B) 



(Q 



(D) 



SUBORD ort> NAME orb.name 

SUBORD Gateway NAME gateway .name 



//GEN: SUPER top 
//GEN: SUPER oib 
// 

//GEN: SUPER otb SUBORD AgentSystem NAME hostname 
//GEN: SUPER OibixSetver SUBORD OfbixORBCoreSegmenl NAME label 

//GEN: SUPER OrbtxScrver SUBORD OfbixBOAScgment NAME label 

//GEN: SUPER OfbixServer SUBORD CORBAApplicationObjcctTVpeCMO NAME label 



//GEN: SUPER OibixORBCoreSegment SUBORD OittxConnection 
//GEN: SUPER CORBAApplkationObjectTypeCMO SUBORD 
(X)RBAAppltcatk>nObjecdnstanceCMO NAME label 



NAME label 



//« 
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ANNEXE IB 



5 (Fichitr de description IDL) 

#include <6fb kU> 
#indude<IRDfc.kiI> 
#indude<OpefDf.kfl> 
10 #indudc <IntcrDf id> 
#indude TimeidT 
tindude *Naming.idJ" 
//essai 

//findude "EvcnlManagcment idl* 
15 #if<fcf FOR_GENERATOR_TIME 

module TimcBasc { 

struct uk>ngk>ng{ 
20 unsigned long low; 
unsigned long high; 

}; 



25 
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ANNEXE2 



CLAUSES DE GENERATION 
Usage : gdmo file.idl > file gdmo 

//GEN: GDMO_MODULE_NAME jllAdra & 
Sp^cifk lenomdu module GDMO gdndrf (par dtfaut : "orbAdm" 
Toutes tes interfaces traduites sort dfclarfes enunseul module GDMO. 
Attention : cette clause doit are ptacfe devant toute instruction IDL. 

(Le gdntoteur ne traduit pas les definitions de module IDL en definitions correspondantes en GDMO, 
mais cr6e seulement un module GDMO). 

//GEN: ASNl_MODULE_NAME Idl2 ^ 

-> nom du module ASN 1 g*i*n* (par dtfaut : Idl ") 

Attention : cette clause doit «tre placde devant toute instruction IDL. 



//GEN: OIDJTAG 15 

-> La valeur pour le composant identifieur (fobjet OID associ* * "corba" 
Ptrinet cf avoir diflKrentes gdntatkms pour uuliser diff&ents kfcntifieurs OIDs 

//GEN: METHOD JTO_ ATTRIBUTE getjabel label 

-> La mdthode "getjabel" est traduite en rattribU label* 

La syntaxe retournde par la mahode est utilis6e comme type d'attribut. 

Aucune m-action est gdndrde pour la mahode, seulement Tattribut spdcifii 



(H) 



(A) 



(B) 



//GEN: MULTIPLE_DECLARE hostname 
-> Quand on mane nom d'attribut est utilise dans difHrcntes interfaces IDL, ceci averut le ga*rateur de 
produire seulement une definition d'attribut GDMO. 

//GEN: IGNORE EvertSchemaMetaDef <® 
-> Specific que rinterface donn6e n'a pas & are traduite en GDMO. 



//GEN: TYPEDEF InterfeceDef Object 

-> Ptrmet de ddinir un type qui est normatement dtfini avec le terme "include". 



(D) 
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//GEN: SUPER root SUBORB AgentSystem Name hostname (E) 
-> lien de nommage name-binding k g6n£rer 

Spdcifie : classes cfobjets sup&ieuies et subordonndcs (ou noms d'intcrface qui sont i traduire en noms 
MOCi 

"root" peut etre sp6tif\6 pour la classe MOC sous la racine de la MIB. 
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Revendications 

1. Precede de generation automatique d'un module (19) d'une 
base d'informations d'administration (MIB) d'une ressource infonnatique (11) 
representee par objets et incluant une architecture d'objets distribues 
(CORBA) selon un langage donne (IDL), consistant a faire un fichier 
(annexelB) de description d'interface dans le langage donne et a appliquer 
ledit fichier a des moyens de generation automatique (52) pour obtenir une 
partie dudit module, caracterise en ce qu'il consiste a ajouter audit fichier de 
description un fichier (annexe 1A) de clauses de generation automatique, une 
clause comprenant au moins un mot cle determinant un mode de generation 
et au moins une caracteristique sur laquelle porte un mot cle, et a appliquer 
le fichier de clauses auxdits moyens de generation pour completer ledit 
module. 

2. Precede selon la revendication 1, caracterise en ce que le 
fichier de clauses et le fichier de description ne ferment qu'un seul fichier 
(100), Tun (annexe 1A) des deux fichiers etant distingue de l'autre par une 
marque (GEN). 

3. Precede selon la revendication 1 ou 2, caracterise en ce qu'une 
clause d'un premier type (A) comprend un mot cle 
(METHOD_TO_ATTRIBUTE), une premiere caracteristique representative 
du nom d'une methode et une seconde caracteristique representative d'un 
attribut, le mot cte indiquant aux moyens de generation de convertir ladite 
methode en ledit attribut. 

4. Precede selon l'une des revendications 1 a 3, caracteris6 en ce 
qu'une clause d'un second type (B) comprend un mot cle 
(MULTIPLE_DECLARE) et un attribut, le mot cle indiquant au generateur 
de generer des classes d'objets a partir dudit attribut. 

5. Precede selon l'une des revendications 1 a 4, caracterise en ce 
qu'une clause de troisieme type (Q comprend un mot cle (IGNORE) et une 
caracteristique, le mot cle indiquant aux moyens de generation d'ignorer 
ladite caracteristique. 
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6. Precede selon Tune des revendications 1 a 5, caracterise en ce 
les moyens de generation ne gerant pas des clauses de precompilation, une 
clause de troisieme type (D) inclut un mot cle (TYPEDEF) et deux mots, le 
mot cle indiquant aux moyens de generation qu'il faut remplacer Tun des 

5 mots (InterfaceDef) par 1'autre mot (Object) representatif d'un type du langage 
donne normalement defini par une partie de code (sous #include) dans le 
fichier de description. 

7. Precede selon Tune des revendications 1 a 6, caracterise en ce 
qu'une clause de quatridme type (E) comprend trois mots cles (SUPER, 

10 SUBORD, NAME correspondant respectivement a trois caracteristiques (orb, 
AgentSystem, hostname), deux des mots cles designant par leurs 
caracteristiques correspondantes deux instances de classes respectivement 
superieure et inferieure et le troisieme mot cle designant par la troisieme 
caracteristique l'attribut de nommage de la classe subordonnee. 

i5 8. Precede selon Tune des revendications 1 a 7, caracterise en ce 

que les objets etant identifies par des identifieurs (OID) ayant un meme 
prefixe, une clause de cinquieme type (H) comprend un mot cle (OID_TAG) et 
un entier (15), le mot cle indiquant au generate ur de prendre un pre fixe 
different et defini par ledit entier. 

20 9. Precede selon Tune des revendications 1 a 8, caracteris£ en ce 

que les moyens de generation comprennent en outre un generateur (54) pour 
la generation automatique d'une partie (51c) d'un inte grate ur d'agents 
d'administration (51). 

10. Systeme d'administration (10) d'une ressource informatique 

25 (11) representee par objets de finis dans une base d'informations 
d'administration (MIB) incluant un module, le systeme d'administration 
incluant au moins un processeur (14) et des moyens de memoire (15) et la 
ressource informatique incluant une architecture d'objets distribues (CORBA) 
selon un langage donne (IDL), caracterise en ce qu'il met en ceuvre au moyen 

30 d'au moins ledit processeur (14) le procede defini par Tune des revendications 
precedentes. 
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